1. Field of the Invention
The present invention relates to a service providing system. More specifically, the invention relates to a service providing system advantageously applicable to, for example, a web-VoIP (Voice over Internet Protocol) cooperative type of application software (AP) environment in which the web-AP server environment providing application software running in the WWW (World Wide Web) environment is cooperative with the SIP (Session Initiation Protocol) server environment, which is a VoIP server environment implemented by the SIP, that is one of the typical protocols for implementing VoIP.
2. Description of the Background Art
Recently, between a web server providing a web client with a service using the HTTP (Hyper Text Transfer Protocol) protocol and a web application (web-AP), a web-AP server is disposed to allow the web server to simply function as directly transferring information with the web client. An application software environment, based on such a web-AP server, is dedicated to web applications designed for the HTTP protocol.
In the conventional environment described above, the operation proceeds as follows. First, a web browser, one of web clients, issues a request to the web server via the HTTP protocol (first step). Next, based on the received request, the web server requests the web-AP server to execute application processing (second step). Then, the web-AP server starts the web application responsive to the requested application processing and executes the desired application processing (third step). Finally, the web application transfers the execution result to the web-AP server, and the web server sends out the execution result to the web browser that issued the request (fourth step).
In order to build an application that allows a plurality of users to communicate with each other, it is necessary to implement application software adapted to pass the execution result of a web application requested by one user to another user. The application software is structured to allow a user who wants to retrieve the execution result of some other user to issue a request for it by means of his or her browser and executing the processing flow similar to the first through fourth steps described above. It can be said that one user may thus receive the execution result from the other user in an indirect manner.
The typical configuration of such a web-AP server is implemented usually by the HTTP Servlet container. Multiple web applications, which include Servlets, are placed in the HTTP Servlet container to execute a request received from the web server. A request from some other browser is processed based on the same mechanism. Therefore, the processing of making the processing result from a request by one user associative with a request by some other user is also usually executed in the Servlet.
For example, when a user accesses a web page to place an order for, a product according to the sequence of the first to fourth steps described above, the vendor who receives the order checks the order contents by a separate procedure according to the sequence like the first to fourth steps. The vendor checks the order contents at a time the vendor wants to do so. Therefore, the vendor does not know whether or not the order is placed until the vendor checks it.
A typical web application that implements the specifications for HTTP Servlet (No-Patent Document 1) is Tomcat (Non-Patent Document 2). However, even if Tomcat is applied, a plurality of users must work together indirectly as in the above situation; that is, one user issues a request and the other user retrieves the processing result for the request. For the HTTP Servlet, reference may be made to the web site, http://java.sun.com/products/servlet/. Also for the Tomcat, the web site, http://java.jakarta.apache.org/tomcat/ may be referenced.
However, such an indirect cooperation cannot establish peer-to-peer communications between web clients. More specifically, in the conventional web-AP server environment, it was difficult to create a real-time communication-type application requiring real-time update and cooperation. For example, it was difficult to create an application that allows a buyer and a vendor to work together in real time when an order is placed.
Another problem with the conventional web-AP server environment is that only the HTTP protocol can be processed. Therefore, other communication protocols cannot be handled in a general framework, and it is thus difficult to create an application where different multiple protocols are combined with each other. There is a need for a service providing system that allows a plurality of application users to work together in real time and that can handle multiple protocols.